.png)
Här kommer ett nytt nyhetsbrev fyllt till bredden med personligt utvalda godbitar från OT-säkerhetsvärlden. Du får ett nytt boktips, en premiärvisning (i Norden) av en riktig OT-tungviktare, spretiga tankar kring standarden 62443, ett ramverk kring insiderbrott och en massa annat spännande!
Om det är första gången du läser ett av mina nyhetsbrev kanske du undrar vad det där "OT" är som jag pratar om? OT står för Operational Technology vilket är ett syskon till IT, Information Technology. Med IT använder man teknik för att hantera information. Inom OT använder man liknande teknik men för "Operations", alltså att få fysiska saker under kontroll. Det kan exempelvis vara att styra maskiner i en fabrik, elproduktionen i ett kraftverk eller kemiska processer i ett raffinaderi. Inom IT är fokus ofta på att skydda hemligheter men inom OT blir det oftast viktigast att hålla en funktion tillgänglig och korrekt. Det innebär att säkerhetsarbetet kommer se väldigt annorlunda ut, vilket är anledningen till mina texter. Jag skrev nyligen ett inlägg på Atea-bloggen som förklarar mer.
Jag vill ge er ett stort tack för alla trevliga mejl jag får med frågor, förslag och uppmuntrande ord. Som vanligt vill jag gärna att du delar med dig av nyhetsbrevet till kollegor som kan vara intresserade! Ju fler som läser, desto bättre möjligheter får jag att producera bra innehåll framöver! Om du vill ha nyhetsbrevet i inkorgen i fortsättningen är det bara att dra ett mejl till mig på mats.karlsson-landre@atea.se. Jag lovar att din mejladress inte används till något annat än detta!
Du hittar alla tidigare utgåvor av nyhetsbrevet på www.ot-säkerhet.se. När det kommer nytt material så annonserar jag det på en massa ställen: min Linkedin-profil, i en egen LinkedIn grupp, i Facebook-gruppen Säkerhetsbubblan, på Twitter och på en egen Facebook-sida. Du kan också prenumerera via RSS på www.ot-säkerhet.se. Framöver kommer också en kopia publiceras på Ateas officiella blogg tillsammans med en del annat som jag skriver där.
Ge mig gärna mothugg, frågor eller förslag på LinkedIn där den här utgåvan delades. Tänk på att du kan hjälpa mig, mer än du kanske tror, genom att trycka "like" på artikeln och genom att dela den vidare. Tack för hjälpen!
Konsekvensdrivet säkerhetsarbete - Ett boktips (till...)
Om du läste om boken "Security PHA Review for Consequence-Based Cybersecurity" i förra nyhetsbrevet så kanske du undrar om det här är en repris? Men det är det faktiskt inte! Det märks om inte annat på att den här boken är nästan tre gånger så tjock.
Men det är verkligen inte bara barlast som fyller boken, det är väldigt mycket matnyttigt! Det som presenteras är en metod som kallas CCE, "Consequence-driven, Cyber-informed Engineering", slarvigt översatt så handlar det om hur man arbetar ingenjörsmässigt med att hantera konsekvenserna av olika typer av händelser med blicken stadigt fäst på de utmaningar som modern teknik tillfört. Historiskt så är det ju precis där vi kört vilse när vi skulle ta oss från tiden när det framför allt handlade om att hantera att OT-komponenter slumpmässigt gick sönder till att kunna hantera medvetna och avancerade sabotage utförda av kunniga människor med insyn i utformningen av de system som angrips. Redan i titeln förstår vi också att den handlar om "Engineering" och inte "Security", det är viktigt att komma ihåg skillnaden!
Författarna, Andrew A. Bochman och Sarah Freeman, arbetar på INL. "Idaho National Lab" är en intressant amerikansk institution som inte riktigt är vad vi är vana vid när vi pratar om "Lab". Vi brukar tänka på vetenskaplig forskning när vi pratar om "Lab" men INL sysslar inte med den typen forskning utan försöker lösa lite mer ingenjörsmässiga problem i samtiden eller den närmaste framtiden. De sysslar med allt från att pressa kärnreaktorer till alla tänkbara gränser, via att kalibrera enorma kanoner för flottans slagskepp, till att testa EMP-attacker. De gör väldigt mycket kopplat till OT-säkerhet, i synnerhet när det gäller elnätet. De är kanske mest kända för "Aurora", en demonstration där de visade där de kunde förstöra en elektrisk generator fysiskt med hjälp en liten snutt programkod.
De går ut stenhårt och målar upp en becksvart bild av våra möjligheter att försvara våra verksamheter mot den ständigt ökande strömmen av attacker högt och lågt. En av mina egna favoritliknelser dyker upp, den av känslan av att stå på ett löpband och springa allt man kan men utan att man kommer framåt en enda millimeter. Drar man av på tempot det minsta så åker man obönhörligt bakåt... Det här sättet att tänka leder naturligt fram till en del andra populära tankesätt, exempelvis att ingen absolut säkerhet någonsin kommer existera (vilket vi bara kan försöka lösa genom att bygga våra skydd i många lager och med ganska stort fokus på att kunna upptäcka och hantera de angrepp som oundvikligen kommer) eller "Assume breach" dvs att vi alltid ska förutsätta att vi är hackade, faktiskt redan innan vi gått i drift.
Den största delen av INLs finansiering kommer från den nukleära delen av amerikanska Department of Energy. Startskottet för CCE kom 2017 i och med ett forskningsuppdrag för att genomlysa OT-säkerhetsutmaningarna för organisationer som kör kärnkraftverk. Kärnkraftsbranschen, där jag själv fick min praktiska säkerhetsskolning, är förmodligen den bransch som förflyttat sig längst när det gäller OT-säkerhet. Man har ju gått mer eller mindre helt elektromekaniska styrsystem till mycket sofistikerade kontrollsystem baserat på modern teknik och längs vägen skapat ett sätt att arbeta målinriktat med alla möjliga former av säkerhet för att möta de vitt skilda utmaningarna som uppstår kring alla de verksamheter och system som krävs för att köra ett kärnkraftverk på ett effektivt och hypersäkert sätt.
Något som intresserade mig är att de refererar till ett väldigt centralt dokument i all världens kärnkraftsverksamheter, IAEA NSS 13: "Nuclear Security Recommendations on Physical Protection of Nuclear Material and Nuclear Facilities". Den definierar bland annat kravet på att arbeta med en DBT, "Design Basis Threat" - på svenska "Dimensionerande Hotbeskrivning". (Alltså vilka hot organisationens system ska dimensioneras för att "tåla".) Tidigare saknades OT-faktorer helt i det här dokumentet men det är nu så klart väldigt centralt i skyddet av dessa anläggningar. Den som är road kan mycket väl läsa detta dokument även om man inte är i kärnkraftsbranschen, exempelvis är IAEAs resonemang kring begreppet "Graded approach" intressant för alla, alltså att man alltid ska anpassa skyddet, både uppåt och nedåt, baserat på hotnivån och konsekvenserna kopplade till det man skyddar. Om du läst mina nyhetsbrev ett tag så vet du att en DBT är något jag tycker är viktigt för alla organisationer, oavsett bransch, om inte annat så för att säkerställa att organisationen är överens med sig själv om hur hoten ser ut. Det gör att man slipper många onödiga diskussioner!
Nå... Nog med sidospår... Tillbaka till CCE! Om man frågar sig själv är "vad kan hända om någon riktigt elak med full kunskap om vår anläggning, om våra system och om våra rutiner får full tillgång och kontroll över alla våra system? De har dessutom alla resurser och all tid de behöver..." När rysningarna längs ryggraden lagt sig lite börjar man leta efter svar och det är då som CCE blir som mest användbar. ...och kom ihåg: svaren vi ska hitta är alltså inte hur vi ska undvika att det händer utan hur vi ser till att konsekvenserna inte blir en katastrof!
Deras budskap till alla som ansvarar för samhällskritisk infrastruktur är benhårt:
Om din verksamhet är det minsta intressant för andra nationer så kommer du angripas av statsfinansierade angripare. Garanterat!
Om du attackeras av dem så kommer de att lyckas. Garanterat!
Det betyder att de förmodligen redan rör sig i dina system. Garanterat! Nästan...
Din egen stat har inga möjligheter att skydda dig åt dig. Garanterat!
Det är under de här bistra förutsättningarna som de målar upp CCE. Och då var vi tillbaka vid "Assume breach", som är den svåraste delen att ta till sig för de som medverkar i en sådan här övning. Alltså att helt ge upp tanken på att hålla angripare ute (eftersom de redan är inne med full access) och istället helt fokusera på att ta ifrån angriparen möjligheten att göra allvarlig skada. Det är ju också därför denna typ av åtgärder inte går att göra med enbart "omskolat IT-säkerhetsfolk". Det måste vara många andra kategorier med, inte minst processingenjörer, eftersom de flesta åtgärder sannolikt kommer göras med hjälp av förändringar i processen och i sättet vi använder våra leverantörer!
CCE påminner mycket om SPR som jag skrev om i förra nyhetsbrevet i det att man flyttar fokus för sin analys till att förstå konsekvenser. I SPR överger man den gamla trötta riskanalysformeln "Risk = Sannolikhet * Konsekvens" som ju fungerar väldigt dåligt för att bedöma mänskliga motståndare eftersom det inte är slumpmässiga händelser. I CCE är det istället det klassiska ingenjörstänket "Risk = Hot * Sårbarhet * Konsekvens" som dissas. I traditionellt säkerhetsarbete, oavsett vilket område det handlar om, har vi nästan alltid tittat på faktorn "Sårbarhet" eftersom den upplevs enklast att påverka. Vi lever i en tid där vi nästan blivit lite avtrubbade av alla enorma sårbarheter som identifieras i system efter system, ena dagen Solarwinds Orion och nästa Microsoft Exchange. Det är här CCE pekar på att vi oundvikligen kommer drabbas av problem och därför måste lägga vårt krut på att se till att konsekvenserna blir hanterbara!
För oss som sysslar med OT-säkerhet finns det en annan vinkel på samma resonemang som passar oss bra. Vi vet att vi under lång tid framöver kommer fortsätta ha svårt att hänga med IT-världen i deras patchningstempo. Det är förstås också ett skäl till att vi inte kan jobba med faktorn "Sårbarhet" som en väg att minska våra risker. Faktorn "Hot" kommer vi aldrig åt, så då återstår "Konsekvens" som möjlig att jobba med!
Men om man ska peka på skillnaderna mellan SPR och CCE så blir det ganska snart tydligt att det finns en anledning till att CCE-boken är betydligt tjockare, det var inte bara författarnas utsvävningar. Där SPR är mer av ett allmänt tänk så är CCE verkligen en tydligt beskriven metod. Författarna säger själva att man "lånat" bitar från en massa väletablerade metoder och listar bland annat Process Hazard Analysis (PHA), ICS Cyber Kill Chain, Design Basis Threat (DBT) och Crown Jewels Analysis (CJA).
Det första man gör i metoden är att identifiera vilka saker som skulle vara det absolut värsta som skulle kunna hända. Frågor i stil med "Vad får oss att gå i konkurs?", "Vad skulle sätta vår anläggning helt ur spel?" och "Vad skulle döda våra medarbetare?" ställs och besvaras på fullt allvar. Tanken är att till en början helt strunta i om det finns teknikbaserade (oavsett om det är IT eller OT) angreppssätt. Vi vill hitta de funktioner i verksamheten som vi står och faller med. Deras grundpoäng är att de flesta verksamheter inte bottnat i den typen av resonemang och att motstånd i stil med "Det kan ju inte hända!" nästan alltid faller platt till marken när man rotar lite djupare. Det här gäller även verksamheter som är duktiga på att förbereda sig på naturkatastrofer och andra slumpmässiga händelser eftersom de oftast tenderar att vara sämre på att genomskåda mänskliga angrepp, och i synnerhet då IT- och OT-baserade sådana.
I steg två, när man har hittat sina värsta katastrofer, börjar man arbetet med att förstå alla sätt som de kan uppstå. Alltså lite bakvänt mot många andra metoder som tittar på konsekvenser kopplat till ett visst system. Det här är ett brutalt arbete där man analyserar "system av system" ner på skruv- och mutter-nivå och verifierar dokumentation mot verkligheten för att säkerställa att man har full förståelse för de utmaningar vi verkligen står inför. Det var här jag insåg vilken sanslöst dyr metod det här är för stora verksamheter, men å andra sidan är det rimligt att en analys av komplexa system blir ett komplext arbete!
I det tredje steget använder vi en variant på "ICS Cyber Kill Chain" för att definiera en väg till de värsting-resultat som vi identifierade i steg 1 med hjälp av de insikter vi skapat i steg 2. Det görs genom att analysera var i verksamhetens processer vi sätter tillit till saker som vi inte har bekräftat att vi kan lita på. Alltså samma tänk som ligger bakom "Zero trust" fast istället använt av en tänkt angripare. Här används alla tänkbara attackvägar - klassisk hacking, angrepp mot supply chain och att utnyttja mänskliga mål.
Den fjärde, och sista, delen i arbetet fokuserar på att ta de attackvägar som skapades i steg 3 och identifiera motmedel mot dem. Grundtanken är att alltid använda "icke-hackbara" åtgärder där det är möjligt och olika former av övervakning eller fällor där de digitala systemen inte går att komplettera med fysiska åtgärder. För att använda begreppen från NIST CSF så föredrar man "Protect", följt av "Detect" & "Respond" med "Recover" som sista alternativ.
Om du inte redan insett det, så är det om CCE försöker hantera de problem som orsakas av OT-tekniken i våra processer men utan att stirra sig blind på att lösningen måste innehålla OT eller ens digital teknik! Det innebär också att CCE inte är svaret på alla våra risker. Det man ska komma ihåg är att det är inte är självklart att man löst alla mindre allvarliga hot bara för att man hanterat de värsta. CCE är inte svaret på alla frågor men det är svaret på ett antal frågor som många organisationer inte orkat ställa.
CCE må vara en tung metodik att ta från A till Ö men för verksamheter som hanterar extrema risker, för sig själva och för samhället, är det ett arbete som måste göras. SPR som jag skrev om i förra nyhetsbrevet är en enklare metod som siktar delvis på samma risker men som inte är lika deterministisk. Beroende på verksamhetens utmaningar får man välja sin egen väg framåt. Om någon av mina läsare har erfarenheter från den här typen av arbete skulle det vara väldigt intressant att utbyta erfarenheter.
Som bok kan jag bara rekommendera den starkt. Förutom att förklara metoden väldigt tydligt finns det en massa annat intressant som också diskuteras. Om du vill höra författarna själva diskutera CCE-metoden har Andrew Ginter har intervjuat dem, var för sig, i två avsnitt av podcasten "The Industrial Security Podcast". Sarah Freeman i ett avsnitt för några veckor sedan och Andy Bochman i ett annat avsnitt som sändes innan boken givits ut.
Tungt skydd för OT!
Jag har tidigare skrivit om de smidiga brandväggarna och IPSerna från TxOne, senast i min artikel om virtuell patchning i nyhetsbrev #23. De kombinerar ett litet fysiskt format med ett stort skydd på ett sätt som gör det väldigt smidigt och elegant att bygga in skydd i maskiner och ute i anläggningar. Och de är ruggade på ett sätt som inger förtroende i sådana miljöer! Den lilla "EdgeIPS" som är "osynlig" på nätverket gör det verkligen enkelt att lägga till ett starkt skydd utan att alls påverka den existerande uppsättningen. Den smidiga "EdgeFire" ger möjlighet att enkelt hantera de adresskonflikter som ofta uppstår när man börjar ansluta nätverk som tidigare varit isolerade. Båda två har en direkt koppling till systerorganisationen ZDI, Zero Day Initiative, som föder den virtuella patchningsfunktionen med zero-days.
Men! Om man inte vill, eller kan, bygga in skyddet ute i sin anläggning så blir det ju lite fånigt att sätta en massa ruggade burkar i sin datorhall eller i nätverksrummet! Det vore ju smidigt att få samma skydd men förpackat i ett lite mer rack-vänligt format? In på scenen kommer då "TxOne EdgeIPS Pro"! Det är 16kg tung fullblods-IPS, helt inriktad på OT men anpassad för att placeras datacentermiljöer. Det finns faktiskt en storebror också, en modell som är dubbelt så stor. Jag har fått möjligheten att klämma på den första enheten som kommit till Norden i mitt lilla OT-labb.
Det är verkligen en rejäl pjäs. Förutom den stadiga vikten är den 80cm djup vilket kräver ett stadigt rack för att kunna monteras. Man skulle kunna tro att det TxOne gjort är bara att kombinera 24 stycken EdgeIPS i en racklåda men det är faktiskt lite mer än så. Den har en del riktigt intressanta funktioner som man inte hittar i den betydligt mindre EdgeIPS.
Tanken är att man sätter den mellan en access-switch och utrustningarna i verksamheten. Nätverksportarna sitter i par där den ena porten ansluts till switchen och den andra till den fysiska utrustningen. Eftersom den nätverksmässigt är helt osynlig kan införandet göras helt odramatiskt när man har möjlighet att koppla om de fysiska anslutningarna.
Apropå drama och de fysiska anslutningarna så är det här vi hittar den första skillnaden mot den lilla EdgeIPS. De har båda två relä-baserade bypass-kopplingar för att inte nätverksanslutningarna ska brytas vid ett haveri eller strömförlust. Men i Pro-versionen kan vi välja hur relät ska agera. "Fail Open" eller "Fail Close" avgörs förstås av om du föredrar att köra processen utan skydd eller om du hellre bryter nätverkskopplingen vid ett fel. Eftersom det här förstås varierar mellan olika utrustningar går detta att ställa in per port! Dessutom finns en tredje inställning, "Force Open", som fysiskt kopplar förbi trafiken helt vilket kan vara praktiskt vid felsökning. Snyggt!
En efterlängtad finess som bara finns i Pro-versionerna är "Packet Capture". Det handlar helt enkelt om att du kan få en inspelning av nätverkstrafiken som triggat en IPS-regel. Det här är förstås helt ovärderligt vid incidentanalys om man saknar generell inspelning av sin nätverkstrafik. Den inspelade nätverkstrafiken laddar man sedan ner i administrationsgränssnittet och öppnar med WireShark eller något annat analysverktyg.
Konfigurationen av brandväggsregler och IPS-skydd är intuitiv och snygg precis som tidigare. Men även här tillför Pro-versionen lite extra. Här finns möjligheter att kombinera klassiska brandväggsregler med filtrering baserat på OT-protokoll, IPS-regler och överföring av filer via olika protokoll. Många OT-verksamheter kan exempelvis ha enorm nytta av att kunna styra och reglera trafik som skickas över SMB version 1.
Annars känner man igen det smidiga administrationsgränssnittet från de tidigare modellerna. Administrationskonsolen levereras som en färdig virtuell appliance som kräver ett minimum av inställningar för att komma igång. Gränssnittet är enkelt och tydligt. Man skapar konfigurationsgrupper vilket gör det enkelt att snabbt få till en väl standardiserad uppsättning även om man har många enheter. Genom att flytta enheter mellan konfigurationsgrupper kan man på ett väldigt smidigt sätt byta en hel konfiguration, självklart utan att trafiken eller skyddet påverkas under bytet!
Summa summarum är det här en fantastisk maskin som, trots sitt datorhallsanpassade yttre, levererar OT-säkerhetsfunktioner som är extremt väl anpassade till operativa verksamheter.
Jag lovade i förra nyhetsbrevet att utsätta det lilla underverket för en del extrema prestandatester vilket jag tänker be att få återkomma till!
Funktionellt är det här unika produkter för den som vill skydda sin OT-miljö och tack vare kopplingen till Zero Day Initiative blir skyddet dessutom riktigt vasst även när det gäller zero-days!
Standarder och sånt...
Jag tänkte dra igång en liten serie korta texter om olika standarder och ramverk med något slags anknytning till OT framöver. Först ut blir förstås min ständiga favorit ISA/IEC 62443 men sedan tänkte jag låta dig läsare tycka till om vad som ska tas upp. Kanske blir det NIST CSF, NERC CIP, ICS Cyber Kill Chain, ISA 95, NAMUR eller någon annan spännande variant. Hör av dig om du har önskemål! Mats.Karlsson-Landre@atea.se
Men jag börjar förstås med ISA/IEC 62443. Men varför då? - blir ju den uppenbara motfrågan. Vad är det som gör den standarden så speciell förutom att det är min egen favorit? Det kanske viktigaste skälet är att den skapades uteslutande för att hantera de speciella förutsättningar som ofta gäller inom OT. Förutsättningar som gör att man inte oftast kan resonera kring risker och kring säkerhetsåtgärder på samma sätt som man gör inom informationssäkerhet. De här skillnaderna har jag skrivit om flera gånger förut, exempelvis kan du läsa mer i nyhetsbreven #25, #24 och #23. Arbetet började 2002 när en grupp kallad ISA99 inom International Society of Automation började ta fram standarden som först publicerades via ANSI och senare via IEC. Det är ett pågående arbete med flera olika delar, så det finns både hål i listan över dokument och en del motsägelser mellan dokument som är olika gamla.
Standarden har fyra delar, även om de flesta bara kommer i kontakt med del 1, 2 och 3.
Del 1 beskriver definitioner och en del allmänna koncept på dryga 90 sidor.
Den viktigaste biten i del 2 är 170 sidor som handlar om hur man sätter upp ett säkerhetsprogram i en OT-verksamhet för att säkerställa att man har koll på sina säkerhetsåtgärder. Del 2 lånar CMMIs mognadsmodell för att ge lite mätbarhet på säkerhetsarbetet. I del 2 finns också två tekniska rapporter, en om patchningsrutiner och en som beskriver krav på tjänsteleverantörer inom OT.
Del 3 är förmodligen den mest välkända. Där spenderas drygt 120 sidor för att definieras konceptet "SL" - "Security Level" där säkerhetsåtgärder graderas från 0 till 4 baserat på ett 50-tal åtgärder med undervarianter. På sätt och vis kan man jämföra det med ISO-27002 inom 27000-serien. Utöver åtgärderna beskrivs också en metod för att bedöma risker och i vilken säkerhetsåtgärder behövs för att uppnå önskad säkerhet.
Del 4 riktar sig till dem som tillverkar OT-utrustning. Den beskriver hur en säker utvecklingsprocess ska se ut och vilka krav som ställs på produkterna.
Som så ofta är inte standard-texterna gratis men genom att bli medlem i ISA för en överkomlig penning får man tillgång till alla deras standarder. De ger också ut intressanta böcker och har också en mängd utbildningar, bland annat de fyra utbildningar med tillhörande certifieringar som jag själv tagit för att stolt få kalla mig "ISA/IEC 62443 Cybersecurity Expert". Den inledande Fundamentals-kursen är ett perfekt sätt att komma underfund med standarden. En stark sida med både böcker och kurser från ISA är att de anstränger sig för att de ska fungera oavsett om din bakgrund är från automationsvärlden eller från IT-världen. En klurig balans att hantera... Som medlem i ISA blir man också insläppt i deras diskussionsforum där det emellanåt går hett till... Vill man, som jag, engagera sig i arbetet med att utveckla standarden eller ta del av nya texter innan de publiceras kan man gå med i arbetsgrupperna utan extra kostnad.
Personligen tycker jag verkligen att 62443 är värd att ta till sig för alla organisationer som på något vis lutar sig mot OT-system. Det är en standard som kräver lite arbete innan man blir kompisar men grundtänket i texterna är ett perfekt stöd för allt OT-säkerhetsarbete. Den går utmärkt att kombinera med ISO 27001 och 27002 om man har information som behöver skyddas i OT-systemen. Jag kan tycka att tänket kring riskbedömningar kan utvecklas och då kan ju exempelvis SPR-metoden som jag berättade om i förra nyhetsbrevet vara en alldeles utmärkt metod.
Killchain för insiders!
Ett gissel i alla former av säkerhetsarbete är att du måste lita på dina medarbetare. En extern angripare kan man förstå, förutse och hantera men att försvara sig mot att en betrodd kollega plötsligt vänder sig mot sin egen organisation är väldigt svårt att hantera för de flesta verksamheter. Det gäller i allra högsta grad även inom OT eftersom en insider ofta har unika möjligheter i och med att man både känner till och kan manipulera de skydd som finns. Det här är av naturliga skäl en stor fråga i min egen gamla bransch, kärnkraften. Där har man sedan länge arbetat strukturerat med denna riktigt svåra fråga.
Jag råkade nyligen snubbla över en artikel från G-Research, en organisation som inte har ett smack med OT och OT-säkerhet att göra. Det är en brittisk forskningsgrupp i finansbranschen. Vad de har gjort är att, med inspiration från de välkända ramverken "Lockheed Martin Cyber Kill Chain" och "MITRE ATT&CK" utvecklat resonemangen från en bok som heter "CERT Guide to Insider Threats" till något de kallar "Insider Attack Matrix" och "Insider Kill Chain".
De säger själva att det krävs mer arbete för att vidareutveckla deras resultat men jag tycker redan det finns riktigt starka delar i detta. Om du är intresserad av ämnet kan jag definitivt rekommendera att du läser deras text. Om du använder killchains eller MITRE ATT&CK i andra sammanhang vill jag gärna höra om du tycker det här är ett vettigt komplement.
En gränsdragning jag gärna skulle vilja se diskuterad framöver är om, och i så fall hur, man skiljer på en insider med ont uppsåt och en insider som blir lurad/manipulerad att göra något elakt. Det är en diskussion som dyker upp ibland och som jag ännu inte sett något tydligt grepp kring.
Lästips!
Dale Peterson funderar kring hur vi ska få fram fler människor med kompetens inom OT-säkerhet. Han resonerar ur ett amerikanskt perspektiv men hans tankar känns relevanta även här. Vi får tre förslag: 1.) Få in fler kvinnor i branschen 2.) Tro inte att det finns massor med folk som redan kan allt utan leta upp dem med bra förutsättningar och lär dem det som de saknar 3.) Belasta inte automationsfolket med säkerhetsåtgärder utan hyr in OT-säkerhetsproffs! https://www.linkedin.com/pulse/how-do-we-solve-ot-cybersecurity-staffing-challenges-dale-peterson
En artikel i ISAs tidning som väckt diskussioner kring hur man ska åstadkomma separation mellan processkontroll och processsäkerhet. Författarna har tittat på hur kravtexter från standarder och leverantörernas egna texter använder olika ord som därmed kan tolkas på olika sätt. Exempelvis "Separation" kontra "Isolation". https://intechdigital.isa.org/publication/?m=60495&i=684843&p=28 Den som är road av ämnet kan också läsa i ISA-rapporten ISA-TR84 Part 9 där man i Appendix A tittar på för- och nackdelar med olika arkitekturer. Vi i Sverige har ju dessutom det besläktade problemet med att "Security" och "Safety" båda översätts till "Säkerhet" vilket jag själv har varit med om att det lett till allvarliga missförstånd.
Jim Gavigan resonerar kring användningen av Historian-tjänster framöver på vägen in i Industrie 4.0. https://www.industrialinsightinc.com/post/2019/08/01/are-industrial-data-historians-an-iiot-platform
Remote Desktop Protocol (RDP) är en vanlig svag punkt när vi bygger den enklaste formen av jumphosts mellan segmenterade nätverk. Center for Internet Security, CIS, har ett bra White Paper kring hur man kan göra så gott det går för att skydda tjänsten. https://www.cisecurity.org/white-papers/exploited-protocols-remote-desktop-protocol-rdp/
Jag har nämnt projektet "Top 20 Secure PLC Coding Practices" förut. Deras arbete för att ta fram riktlinjer för säker programmering av PLCer går framåt och en första publicering planeras till sommaren. Förutom rena programmeringsråd samlar de också in en massa andra klokskaper. Redan nu finns det väldigt mycket att ta till sig om man sysslar med programmering eller kodgranskning. Personligen tror jag att det här arbetet kommer leda till riktigt viktiga framsteg i att göra PLC-program mer tåliga mot påverkan. https://top20.isa.org/
Anmäl dig till MSBs NIS-konferens den 19:e Maj! Perfekt tillfälle att lära sig mer om detta viktiga område oh vad som är på gång framöver! https://www.msb.se/sv/aktuellt/kalender/2021/maj/kunskapshojande-nis-konferens/
Joe Weiss slår ett slag för de underskattade säkerhetsriskerna kopplat till OT-system i våra datorhallar. System för avbrottsfri kraft, eldistribution, kyla, inpassering mm innehåller ofta kompontenter eller använder protokoll som vi känner igen från OT-världen. Om inte de skyddas på rätt sätt är det en riktigt effektiv pungspark mot driften av en datorhall.
Jag skrev en inlägg nyligen på Atea-bloggen om vad OT-säkerhet är där jag beskriver vad OT-säkerhet är och varför det är speciellt tillsammans med några vanliga utmaningar och missförstånd som lätt uppstår.
OTCSA (OT Cyber Security Alliance) har gett ut en serie om tre dokument kring hur man bygger upp en OT-säkerhetsorganisation:
Matthew Loong tittar närmare på säkerheten i de system som ligger allra närmast de fysiska processerna och avslutar med tankar kring hur detta kan förändras i takt med att vi gå in i Industrie 4.0 https://www.linkedin.com/pulse/taking-closer-look-level-0-1-security-matthew-loong/
Ytterligare en standard att hålla ordning på: ISO/SAE 21434 Cybersäkerhet för bilar och andra vägburna fordon. Någon som har mer koll på detta och som vill berätta? https://www.cyres-consulting.com/hello-iso-sae-21434-the-new-point-of-reference-for-cybersecurity-in-the-automotive-industry-is-coming/
Det här nyhetsbrevet skickas till mottagare med intresse av säkerhet inom OT. Det produceras av Mats Karlsson Landré på Atea Sverige och får spridas vidare fritt.
Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats.karlsson-landre@atea.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet!
Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats.karlsson-landre@atea.se. Jag lovar att din mejladress inte används till något annat än detta!
Du hittar tidigare nyhetsbrev på ot-säkerhet.se .